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1 Introduction 

DBGen is a tool for the Coq Proof Assistant. It generates Coq definitions and properties from a 
term structure with binding handUng, providing a framework in the De Bruijn setting. 

2 Source syntax 

The source syntax of DBGen is a valid coq (inductive) term structure annotated with comments 
for binding information, defined inside a module whose name will be used in the generated con- 
tent. We assume the knowledge of basic inductive definitions in Coq and of De Bruijn encod- 
ings. Annotations are given as Coq comments, i.e. between (* and *), placed in strategic loca- 
tions to indicate the binding structure of the defined syntax. 

Example 1. Here follows the source syntax for ordinary A-calculus: 

Module LambdaTerms . 

Inductive term : Type := 

I var ((* index *) x : nat) 

I app (tl : term) (t2 : term) 

I leim ((* bind term in *) t : term). 

End LeimbdaTerms . 

2.1 index annotation 

Given a term structure, the (* index *) annotation must be placed before every index argu- 
ments in any syntactic category. It will generate an index structure for the category, along with 
lifting and substitution functions able to deal with it. 

Remark 2. Indices definition are subject to the following restrictions: 

• Constructors having index parameters (as var in Example 1) may not have other argu- 
ments. 

• Only one index constructor per category is allowed. 

2.2 bind annotation 

Binding annotations arc placed before the subtcrm in which the binding occurs. A binding is 
defined by two informations; the index category that is bound in the subterm and the number of 
bound variables. Shortcut can be used, as in Example 1, when only a single variable is bound. 

Remark 3. 

• Due to the lack of source code static analysis by DBGen, some errors can occur in the 
generated code when incorrect binding information is provided. More precisely, there is 
no verification of the index category name given by the user, and the generated source 
code will not display informative error message in that case. 



1 



2 



Section 3 



• The number of bound variables can be a natural number constant, an identifier (i.e. pre- 
viously defined or declared as a preceding parameter in the same constructor), or an 
arithmetic expression combining constants and identifiers with the coq standard opera- 
tions +, - and *. General expression should be allowed as soon as the developer team will 
embed the coq expressions parser in the tool. 



2.3 Complete BNF grammar 

Here follows the complete source grammar definition. 

mod ::— Module ModuleName. 
nodes 
End ModuleName . 



node 
cat 

constr 
param 

shifts 
shift 



Inductive cats . 

CatName : Type 
CatName : Type 



constrs 

constrs with cat 



I ConstrName params 

((* index *) ParamName : nat) 

((* bind shifts in *) ParamName : CatName) 

(ParamName : CatName) 

shift .... , shift 

CatName 

[ exp CatName ] 



exp 



n 
Id 

exp + exp 
exp - exp 
exp * exp 



3 Generated code 

The output of DBGen is a single file defining a module whose name is exactly the module name 
given in the source file. This allows the user to take advantage of the separate compilation pro- 
cess of Coq. 

The generated module is organized as follows: 

Module ModuleName . 

— Database and tactics definition. 
-- De Bruijn structure definition. 

-- Lifting eind substitution function definitions. 

— Auxiliary structure aind function definitions. 

— Basic functions properties w.r.t. index cases. 



Generated code 
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— Index tactic definition. 

-- Advanced functions properties eind corresponding tactics. 

— Main tactic definition. 
End ModuleJVajne. 

The generated Coq code is quite clear and well presented, this allows the user to check and 
look for definitions and properties he needs in addition to this short (and incomplete) guide. 

3.1 Name of generated definitions and functions 

The initial De Bruijn structure is defined exactly as in the source code: category, constructor 
and parameter names will be identical. DBGen generate also a named version of the syntax 
(with strings constants for variable and explicit binding): a '_' is put as a prefix of every names 
in order to distinguish them from the De Bruijn structure. 

For each generated function, a name is build using the names of the involved syntactic cate- 
gories in order to automatically generate tactics working with those fimctions. The process of 
function name generation might help the end user to easily access the function needed in its own 
Coq development. 

Let us consider the following example (formalization of System F): 

Module SYS_F_terms. 

Inductive type : Type := 

I tvar ((* index *) i : nat) 

I tconst (n : nat) 

I tarrow (A : type) (B : type) 

I tall ((* bind type in *) A : type). 

Inductive term : Type := 
I var ((* index *) x : nat) 
I app (tl : term) (t2 : term) 

I Icim (A : type) ((* bind term in *) t : term) 

I tapp (t : term) (A : type) 

I gen ((* bind type in *) t : term). 

End SYS_F_terms. 

Given such a grammar with syntactic categories ri, r„, among which r^^, t^j. contain an 
index constructor, DBGen will produce, for every a lifting and a substitution function for 
every categories Tp from which the grammar graph allows to reach r^^ (including t^^ itself). 
Hence, for a given pair (rj^, Tp), the function name will be build from the names of those cate- 
gories. 

• Lifting function name: Tj^_lif t_in_Tp, its type will be nat -> nat -> Tp -> Tp. 

For our example, it gives us three functions: type_lif t_in_type, 
type_lif t_in_term and term_lif t_in_term. 

• Substitution function name: Ti^_subst_in_Tp, its type will be r^^ -> nat -> Tp -> Tp. 

For our example, it gives us three functions: type_subst_in_type, 
type_subst_in_term and term_subst_in_term. 

The developer can use those function, for instance, to define /3-reduction (as a predicate 
reduce): 
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forall t u : term, reduce (app (Icun t) u) (terin_subst_in_term u t) 

Some functions process the grammar only once, without the need of a specific treatment for 
every indexed categories, for instance the translation function from the named syntax to the De 
Bruijn syntax. In such cases, only the Tp name is used. 

3.2 Name of generated infrastructure and tactics 

At the beginning of the module, a hint database is declared in order to take advantage of coq 
automation. Its name is build from the module name as follows: 
Create HintDb ModuleJ\rajne_database . 

A tactic is then immediately defined to use this database and perform trivial simplifications 
and arithmetic proofs (using the library Omega), named crush_tac. This tactic is intended to 
be quick in its work. Another tactic, named ecrush_tac, is similar to crush_tac but use eauto 
instead of auto. 

Several other tactics are the defined, whose goal is to simplify arbitrary terms containing 
generated function in order to help the end user to perform subsequent proofs. The main tactic, 
named dbgen_tac, which combines the strength of all the generated tactics, is probably pow- 
erful enough to deal with any specific case. The other tactics can of course be invoked sepa- 
rately by the user, their definitions and names are to be found in the generated module. 



4 Usage 

The DBGen tool takes as argument the source file name and the output file name. If a file exists 
with the given output file name then it will be replaced by the generated file. 

usage: dbgen [ -version ] [ -debug ] in-file out-file 

The -version option causes DBGen to print its version number and immediately exit. The 
-debug option displays informations about the internal treatment for debugging purposes. 

4.1 Examples 

Several examples are provided in the Test subdirectory. 
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